Yes. So, 20-year IT veteran, have been in the Agile space for the last seven or eight years. My last kind of corporate gig was running a large portfolio of projects in the financial services industry and kind of through that time developed a passion for helping companies that are dealing with larger, more complex Agile implementations to try to be successful. And so, after I left that company, I spent a couple of years as a coach-consultant for VersionOne and really for the last couple of years, had been out on my own running LeadingAgile.
Well, I've a kind of funny story. If anybody out there watching us, it's from Atlanta. You know at the early part of this year, we had what we call snowmageddon and we were all trapped in our houses for about five days while Atlanta was totally unable to get rid of the ice. And so, we were all trapped and I was reviewing sessions for the Agile 2011 Agile Adoption and Transformation Stage.
And one of the things that really caught me as I looked at all the different parts about the adoption and transformation was how we all look at it somewhat differently. So I started trying to untangle it a bit and to develop some language around it. And one of the conclusions that I came to was that there's actually a difference between adoption and transformation and we tend to use these things interchangeably like, "Yes, we're going to adopt and transform it, just like it's a one big event."
And in my point of view, I think it's helpful as we look at introducing Agile methods into organizations if we look at those two things separately. So I'd tend to think about adoption as the introduction of practices. So, from a Scrum perspective, I might be thinking about daily standard meetings or reviews and retrospectives or having a Product Owner role or a Scrum Master Role instantiated. But that's different from actually transforming the organization or transforming who you are as a person.
And so, if you look at adoption as the introduction of practices, transformation is really the introduction of change and so I'd like to think of adoption in two different categories as well. So, we have the idea of organizational transformation which really centers around the structures and the policies and the working agreements within your organization.
And then you have personal transformation which is changing who you are as a person, how you think about leadership, how you think about teams and individuals and the organization. So, looking at adoption and transformation from these three different perspectives, is tremendously clarifying from my point of view in terms of getting into an organizational and helping them change.
So it's interesting. So, I think there's a set of implied value statements that people get this kind of a promise of adopting Scrum something like that where we're going to get better collaboration and better team work. We're going to get more efficient product delivery. We're going to get better quality. We're going to get faster time to market - and those are all the things that we want.
But very often what happens is that in the attempt to get those things, we focus on the practices in and of themselves as if the practices that we adopt are going to automatically guarantee us those business results. And so, like I said, it's all about getting products to customers faster and having happy customers, having satisfied customers, getting good return in investment in the investment in our product delivery teams - those are the things we want.
Agile practices are really just a means to an end in that regard. And the reason why I want to call it out, I probably sound somewhat obvious but very often, we get so focused on introducing a specific set of practices that we lose focus on the goals. It's not uncommon for me to go to an organization that's been trying to do some flavor of Agile for a period of time.
And we have all the remnants of those process elements existing but they're not getting the value out of it. And you go, "We're Agile, right?" because we're doing all these things.
And the goal was never to instantiate these practices. The goal is the business outcomes. So, these practices aren't leading to the business outcome there is a problem that has to be addressed and ideally that's a problem that we want to adjust proactively at the beginning of the adoption and transformation cycle rather than having to just instantiate these things, fail and then have to circle back, because at that point, because very often people have lost confidence that these practices can help propel their business forward.
I mean, yes, they're usually they're pretty clear and it's almost you discover them by looking at what the organization is trying to accomplish by going down this path. So, very often organizations are dealing with profound product quality issues and markets and these are reflected in terms of their customers calling them and demanding certain things to be fixed. Maybe, they're spending, $45 million a year on their development team and they're not getting any new features in the market and they can't understand why.
And so, a lot of times, you go in and you talk about people about what their pain points are from a business perspective, you get a pretty clear understanding of what it is that their value drivers are. And so I find that's not usually a hard conversation because organizations that have either gone down this pattern failed or are contemplating such a profound change within their organization; they usually too a point whether they're feeling a significant amount of pain that they got to do something about it.
Now that said, sometimes you get into an organization that's doing Agile or maybe they're even doing a more traditional development approach and they just want to get better and improve - that's kind of where that conversation happens which is like anything, it's usually a facilitated conversation. You know, we brainstorm and collect ideas for that kind of things, prioritize; but again, it usually all come around to return on investment at the end of the day because ultimately yes, we want a great organization, we want to have great teams but if we're not generating revenue for our shareholders or stakeholders or you know, our owners or whatever, we're not often successful for very long.
So I will go back to the kind of three-pronged Agile adoption and transformation cycle that I talked about. And so, if you aren't able to address all three aspects - your organizational change aspects, the practices and tools aspects and the personal transformation aspect, it's very difficult to get the introduction of Agile methods to all hang together and to be a cohesive whole.
So you see patterns like people or manager will introduce the ceremonies and the artifacts of Scrum but they didn't fundamentally change the organizational structure to be congruent with it. They didn't form complete teams; so they are matrixing and people across multiple teams - those are things that cause problems for Scrum.
You'll also see things like where maybe they change structures and practices but they haven't gone through the kind of change management required to help folks really kind of change hearts and minds and so, you might have the structure and you might have the practices but at the end of the day, these practices aren't being practiced with the right intent.
And so, most of the things that I see are problematic with existing Scrum or not just Scrum but any kind of Agile implementation is that there's remnant or some piece of it but it wasn't a fully completed transformation event. And so, you end up with pieces and parts but you don't get an integrated whole and therefore, you don't get the business outcomes that you are waiting for.
You may be laughing about the technical writers because there's never enough technical writers in any organization for what they want to achieve so they are heavily matrixed. And so Agile methods can handle some degree of matrixing. So you go back to kind of PMI PMBoK model and when you talk about matrix organization, you typically have strong side of the matrix and a weak side of the matrix.
And so most traditionally managed organizations the strong side of the matrix tends to be the functional organization in the sense that the development manager or the QA manager has the power to decide how things happen and in a projectized organization, or team-based organization, the primary affinity is to the team.
And so first of all, one thing I want to say is that it's not typically trying to go and break up management hierarchies, that's a kind of conversation for a different day, but we're trying to shift the strength of the matrix from the functionally aligned manager to the team.
And so one is challenged with that and you hit it on it in your question is the idea of a belief that individual utilization leads to better product delivery outcomes or projects delivery outcomes and I believe that's a myth and I think we're learning that. I think the emergence of Lean in our community and the idea of value stream mapping and things like that, is helping us to understand that it's not really the utilization of the individual that matters - it's really the productivity of the team or the unit of people that creates the product.
And so, you know, so kind of a first pass at that, you talked about the idea of Agile introduces specializing generalist where we have a variety of skillsets on the team that is collectively responsible for delivering an increment of product. And people tend to get that kind conceptually but if they're used to operating a functional silos it's very difficult to think about you know, as an analyst, I might help the QA tester test. The tester might actually help do some of the automation and the developer might actually help do some of the functional testing in the end.
So one of the things that Agile is trying to do to reduce the matrix as required is I guess specializing in generalist.
Very often, I get into a conversation with a developer who says, "Hey," and he goes, "I'm the developer. I want to develop. That's the only thing I want to do is develop, that's what I'm good at - it's developing. So you should let me develop." But if the developer is writing a bunch of code that it cannot be tested, then we don't have a bunch of delivered product, right? We have a bunch of untested code which is something that we don't want. And so, one of the things that I'll often say explicitly to them is that we may sub optimize your performances as a developer to optimize the value creation at a team level.
So I want to increase the output of the team even if that means I sub optimize the developer. Now ultimately what I want to do is bring that organization into balance and so, you know, I want the development capacity to be balanced with the QA capacity which is balanced with its ability to put stuff in the market, you know, all across that entire value stream. But if I got to do that by subordinating the developer to tester, will do that, right? And that's what gives us the ability to build team.
Yes, it's a tough one and you know, because a lot of times when you walk into an organization, you're kind of confronted with their realities and so yes, ultimately I would love to have the documentation and kind of go ride along or with the rest of the software development process. Just in reality sometimes it just doesn't happen. So, you know, one of the things, kind of getting back to Lean value stream conversation that we're having is I can handle to some degree certain shared resources across teams but the challenges is that if that person is a constraint within that organization, if you actually have to have documentation in order to be able to deliver the working software, then you're going to find that person's a bottleneck pretty quickly and you're going to have to do something about it.
And then so you have the developer do the writing or you hire more technical writers or you do something like that. So the question and I'll leave with in that case to product management organization that says, "Would you deliver the product without this documentation?" And if the answer is ‘yes', then I can think of those as two separate user stories and decouple them and I can handle the matrix thing a little bit more. If those two things are tightly coupled to where we can't deliver the product without this increment of documentation, then I'm much more demanding I guess about having that technical writer actually on the team or somebody on that team do the technical writing.
So the question is really about how do you change the QA mindset? A lot of times it starts with how the leadership is incented. So I had one particular scenario where the director of the QA, after I got to know him a little bit, I learned he was largely rewarded for bringing a found defect list to the management meeting and so if he could show the number of defects that were found, the number of defects that got removed- all those things. That is how he supported his boss in terms of his career, right? And so that kind of raises his awards and things like that.
So when I told him, "You know, well what we want is to encourage a collaborative behavior between the QA and the engineer and what we don't want to do, we want to prevent defects from happening in the first place - that was a very foreign concept to him and until you change that external incentive, that's a difficult conversation to have. But assuming that kind of incentive is not in place, what we're try to do is we try to involve the QA tester very early in the process, make them an integral part of whether it be sprint planning or whatever kind of planning that we're doing. And then, getting developers delivering in thin slices, giving the developers constant feedback as we go, creating that partnership between the two.
And what starts to happen is that it's just not the developers or the QA's persons' perspectives that shifts it'sthe developers perspectives that shift because they can't be successful without the software being tested. So, they start to look for ways to help the QA tester be successful that may reinforce the relationship, it creates a loop. It gets further reinforced by product acceptance at the end of the Sprint and it just kind of creates success and you get people working together as a team.
Yes, so it's interesting. So, that can be a pretty big question at times and in this situationally specific to the client that you are working with but I spent a lot of time early in my Agile career especially back in the days when I was working with companies. You get very enthusiastic like you kind of found a way and you're excited and you want to tell people about the way and you can communicate to them and you can talk to them and you can share your enthusiasm with them all you want but in the end of the day, if again, the structures in your organization and what their incentives are, are not congruent with what you're preaching, then it falls often on deaf ears.
And so, to change the mindset of people, I believe you got to create a container for them, a team or some construct in your organization that allows them to do the stuff that creates the environment and then you teach them how to do it and then when they have success in doing it and that success is reinforced over time, then they start to change how they think about it. And that doesn't happen all the time. But it happens often.
So that's the kind of a team level kind of as you're thinking about this but very often it's not hard to get team members to think about it. Sometimes it's hard to get the leadership to think about it.
So, if you're going to an organization and you get teams and place and everybody gets it but yet the managers or the director-level people aren't getting along or they're working against each other or they're coaching their people to work against each other, that becomes problematic. So, you got to understand where those things are. You have to figure out where those dysfunctions are happening and work to get those things out of the way.
As a matter of fact a couple of weeks ago, I ran a workshop for the leaders of this one organization around Patrick Lencioni's Five Dysfunctions of a Team Material, not Agile coaching kind of thing but, you know, if they can't build on that foundation of trust, there's no way that they can encourage their team members to pay attention to results and actually organizational results.
So changing culture is hard. You got to create an environment where that culture can change. You have to change the metrics surrounding it to give people clear things what to do and then you have to hold them accountable for that and then do the coaching and get them to work together at some point. It just takes time wherein people won't flip on this stuff overnight.
Okay. So, first of all, I can't say it's never happened. I've not ever been in an environment where I think kind of a big bang adoption and transformation purchase of the right idea. I also don't think the idea of a single Scrum pilot that's the proof of this works here is necessarily the best strategy either. I think effective adoption and transformation strategies began with some sort of assessment of the organizational and a - kinda, what started off as like an architecture plan or an architectural framework from which we're going to build upon. It's not that that's going to be cast in stone and we're not going to learn on it and adopt it as we go. But the general idea is that we want to understand where we're going to start building these containers, where we're going to start building these teams, how we're going to get these team members trained, how we're going to get the hearts and minds changed over time.
We have to look at and have an understanding of how we're going to do program management, portfolio management - things like that, how we're going to deal with intake, how we're going to interface with the marketing department and the sales department and, you know, all the other downstream support organizations, employment and sales and pre-sales and all these different stuffs.
So that's why I like the idea of top down intetn and bottom up implementation. And so, if you think about how we build software, to me it's very similar matter; we can start with foundational architecture and then we increment the product as we go in the sense that we add more and more features but we also continuously refine these features as we learn more about the emerging solution.
And so, from an organizational perspective, we start with this top level kind of organizational architecture. We begin the process of instantiating teams and introducing the ideas that enable us to do the kind of Agile program portfolio management. And then we begin and we learn and we learn as we go and then we begin to expand those out broader and broader into the organization. But once we've touched the team and that team's not done, that team is continuously improving the portfolio management stuff - these are continuously improved.
As we're moving horizontally on the organization, we're introducing things at a deeper level. And so, I think it helps if you can communicate to senior leadership that this isn't an overnight thing. We're going to in phase 1 we're going to see a certain level of success and a certain breadth of adoption and we're going to go horizontal to the organizational. We're going to see things continuously improve over time with some metrics around that kind of stuff. It helps understanding what your baseline is and how that baseline is improving over time. But it's pretty easy with these kinds of things because again, people's thinking about this doesn't flip overnight.
So, we have to get a good communication strategy, good change management strategy so people understand what to expect and they understand in advance the challenges that these teams are going to face.
One of the biggest things of about adopting Agile is that Agile is really a framework for kind of showing you your organizational dysfunction. And so a lot of times you start to go down this path and things seem worse before they get better or they seem worse and there's not commitment to fixing the things we find and we actually may have made it worse because, or maybe had not made it any better, right, because the dysfunction was there before we'd seen it but now everybody's living in the midst of it.
So how can people understand that process in being able to create, you know, kind of learning organizational around it so we can iteratively and incrementally move our way to that organizational architecture, continuously improve and continuously inspect and adapt and ultimately to get that kind of value - why do we adopt it? And be able to immeasurably say, "Yes, we had improved and this is how we improved it." And this is by how much we've improved it.